PATENT APPLICATION 
Docket #32079/87uspx 



EXPRESS MAIL Mailing Label No 




TEST BENCH GENERATOR FOR INTEGRATED CIRCUITS, 
PARTICULARLY MEMORIES 

PRIORITY CLAIM 

The present application claims priority from 
European Application for Patent No. 02425415.3 filed June 
25, 2002, the disclosure of which is hereby incorporated by 
5 reference. 

BACKGROUND OF THE INVENTION 

Technical Field of the Invention 

[1] The present invention relates to electronic design 

automation (EDA) and, more particularly, to a system and 

10 method for the automatic generation of test benches 
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suitable for verifying integrated circuits, with particular 
reference to memories. 

Description of Related Art 
[2] Exhaustive verification and testing is a major 

5 issue in the process of achieving quality custom integrated 
circuits and ASICs (Application Specific Integrated 
Circuits) . 

[3] Despite the latest advances in verification 

technology, it is very hard and rare to obtain safe and 
10 robust ASICs which work correctly the first time they are 
manufactured, so that it is often necessary to review the 
design in several steps, each time a misbehavior is 
encountered. 

[4] Due the increasing complexity of ASICs and circuits 

15 in general and to the major effort required in testing and 
revising hardware .components, exploitation of electronic 
design automation is today a mandatory choice. 
[5] Electronic design automation is a computer-based 

technology that provides designers with automated or semi- 
20 automated tools both for the designing and the verifying of 
custom circuit designs. 
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[6] It is thus used for creating, analyzing and editing 

several kinds of electronic designs for the purpose of 
simulation, emulation, prototyping, execution or computing, 
and to develop further, complex systems which use a 
5 previously user-designed subsystem or component. 

[7] Typically, the end result of an EDA session is a 

modified and enhanced design that is an improvement over 
the original design, without departing from the original 
aim and scope of that initial design. 

10 [8] Since EDA is heavily based on software prototyping 

and simulation of integrated circuits, specific languages 
have been introduced to permit the specification of 
hardware through software. Such languages are usually 
referred to as Hardware Description Languages (HDL) . 

15 [9] In fact, despite the latest advances in electronic 

designing which have helped significantly in reducing the 
design-to-product time scale, the complexity of today's 
ASICs is such that self -checking HDL test benches have 
fully replaced the simplistic vector-based methodologies 

2 0 used in the past. 

[10] Unfortunately, developing a self -checking test 
bench is a difficult and time consuming task: recent 
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surveys show that this process can easily consume between 
50% and 70% of the overall design schedule. 
[11] In other words, the so called verification problem 
is growing because both the design complexity and, in 
5 parallel, the required amount of stimuli required for a 
comprehensive circuit test, are growing. 

[12] A typical test bench development process involves 
a combination of preparing or purchasing models from 
independent suppliers, doing large amounts of HDL coding, 
10 manually gluing the pieces together and developing an 
exhaustive test sequence to evaluate the behavior of the 
ASIC in its intended environment. 

[13] Nowadays, it has become clear that even state of 
the art verification techniques are breaking down as ASIC 

15 complexities increase, and the trend is such that this 
already extremely difficult and time consuming task is 
getting more and more complex and critical. 
[14] Therefore, a strong need exists in the industry for 
a new system and method overcoming the problems of the 

20 state of the art. 
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SUMMARY OF THE INVENTION 

[15] The aim of the present invention is to provide a 
system and a method which allow to cut down the amount of 
time required in the generation of test benches for 
5 verifying ASIC circuits, with particular referral to 
memories, so as to reduce in a significant manner the 
design cycle time. 

[16] Within this aim, an object of the present invention 
is to provide a system and a method that easily create a 
10 set of test benches for the circuit or memory to be 
verified. 

[17] Another object of the present invention is to 
provide a system and a method that automatically generate 
a most comprehensive test bench according to available data 

15 specifying the ASIC or memory, covering all of the known 
aspects involved in the verification of circuits. 
[18] Yet another object of the present invention is to 
provide a system and a method that provide for automatic 
stimulus generations and re -usage of data. 

20 [19] This aim, these objects and others which will 
become apparent hereinafter are achieved by a computer 
based test bench generator for verifying integrated 
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circuits specified by models in a Hardware Description 
Language. The generator includes a repository storing a 
general set of self -checking tests applicable to the 
integrated circuits. Means are provided for entering 
5 behavior data of an integrated circuit model and entering 
configuration data of the integrated circuit model. Means 
for automatically generating test benches in said Hardware 
Description Language are also provided and are configured 
to make a selection and setup of suitable tests from the 
10 repository according to the specified integrated circuit 
model, configuration and behavior data. 

[2 0] This aim and these objects are also achieved by a 
method for verifying integrated circuits specified by 
integrated circuit models in a Hardware Description 

15 Language. The method stores a general set of self -checking 
tests applicable to the integrated circuits in a 
repository. Behavior data of an integrated circuit model 
and Configuration data of the integrated circuit model are 
entered. Suitable tests from said repository are selected 

20 and set up according to the specified integrated circuit 
model, configuration and behavior data, so as to generate 
test benches in the Hardware Description Language. 
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[21] The integrated circuit can be a memory specified by 
a memory model, which memory may be of any kind, including 
random access memory (RAM) , read only memory (ROM) , 
erasable and/or programmable read only memory (PROM/EPROM) , 
5 and be either synchronous or asynchronous, single port, 
dual port or multi port. 

[22] Conveniently, the general set of tests may be 
generated in the same Hardware Description Language used to 
define the memory model, which language is preferably the 
10 Verilog language. 

[23] On the other hand, the behavior data of the 
integrated circuit or memory under test may be preferably 
specified in a proprietary language, so as to simplify its 
specification. 

15 [24] The configuration data of the integrated circuit or 
memory under test is preferably inputted to the generator 
through a command line or a configuration file, thus 
permitting a quick and handy configuration. 
[2 5] The test bench generator may advantageously select 

20 the tests applicable to the integrated circuit or memory 
under verification according to conditional statements, 
specifying whether a certain test is to be performed on a 
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certain circuit according to the circuit behavior and 
specification, or through any other suitable means, for 
instance by checking multidimensional correspondence 
matrices storing indices of tests applicable to certain 
5 kinds of circuits. 

[26] Since the generation of test benches starts 
directly from the original design specification provided by 
the designer, the resulting test bench is guaranteed to 
match the design requirements. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

[27] A more complete understanding of the method and 
apparatus of the present invention may be acquired by 
reference to the following Detailed Description when taken 
in conjunction with the accompanying Drawings wherein: 

15 [28] FIGURE 1 is a schematic view showing a system 
according to present invention; 

[2 9] FIGURE 2 is a data flow diagram showing an 
algorithm used for development; 

[30] FIGURE 3 is a data flow diagram showing an 
2 0 algorithm for reading memory configuration; 
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[31] FIGURE 4 is an exploded version of the data flow 
diagram of FIGURE 3, showing an algorithm used for reading 
memory configuration in a preferred embodiment; 

[32] FIGURE 5 schematically shows the block structure of 
5 a proprietary language for writing input files according to 
the present invention; 

[33] FIGURES 6a and 6b show reference signals 
respectively providing "0-1-0" and "1-0-1" transitions; 
[34] FIGURE 7 is a data flow diagram showing an 

10 algorithm for generating reference memory cycles; 

[35] FIGURE 8 is a data flow diagram showing an 
algorithm for generating self testing routines; 
[36] FIGURE 9 is an exploded version of the data flow 
diagram of FIGURE 8, showing an algorithm for generating 

15 self testing routines in a preferred embodiment; 

[37] FIGURE 10 is a data flow diagram showing an 
algorithm for instantiating functional test cases; 
[38] FIGURE 11 is a data flow diagram showing an 
algorithm for instantiating calls for edge and ftype test 

20 cases; 

[39] FIGURE 12 is a data flow diagram showing an 
algorithm for timing test cases; 
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[40] FIGURE 13 is a data flow diagram showing an 
algorithm for instantiating simultaneous access test cases; 
and 

[41] FIGURE 14 is a data flow diagram showing an 
5 algorithm for the generation of a header file. 

DETAILED DESCRIPTION OF THE DRAWINGS 

[42] FIGURE 1 shows an overall view of a preferred 
embodiment of the system, which is preferably a computer 
based system provided with hardware and software means for 
10 entering input data, generating and executing test benches 
and outputting verification data. 

[43] A preferred embodiment will be now described with 
specific regard to memories and correspondent memory 
models. However, one skilled in the art will appreciate 
15 that this choice has been made for clarity reasons only, 
and that it shall not be considered as a limitation of the 
system. The same concepts and description are in fact 
applicable to any kind of ASIC. 

[44] FIGURE 1 shows two main modules: a test bench 
20 generator 1 and a simulator 2; it further shows a memory 
model repository 10 storing general data concerning as many 
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kinds of memories as are available or useful for the 
designing activity, a specific memory model 20 to be tested 
and verified, behavior data 21 describing the behavior of 
the specific memory model 20, and configuration data 22 for 
5 setting up the configuration of the memory model. Such 
data is input data to the test bench generator 1 for 
generating test benches 30. Finally, FIGURE 1 shows timing 
data 23 and report data 40. 

[45] The operation of the system is as follows. 

10 [4 6] A number of memory models are stored in the memory 
model repository 10, and catalogued according to structural 
and functional characteristics. Such structural 

characteristics include, but are not limited to, the type 
of memory (ROM, RAM, PROM, EPROM and so on) and the number 

15 of ports (single, dual or multi port) , while functional 
characteristics include information indicating whether a 
memory is synchronous or asynchronous. 

[47] The repository is flexible, in that further models 
may be freely added as soon as they become available, 
20 together with information describing their characteristics. 
[4 8] The memory model 2 0 is the memory under test, as 
designed by the designer. The memory models stored in the 



Dallas2 983884 v 1. 32079. 00087VSPX 



PATENT APPLICATION 
Docket #32079/87uspx 



repository 10 and the memory model under test 20 may be 
specified by means of a Hardware Description Language 
(HDL) , which, in the preferred embodiment, is the widely 
known and used Verilog language. The formal syntax 
5 specification of this language may be found for instance in 
the Language Reference Manual available from Open Verilog 
International (OVI) . It is also to be noted that a Verilog 
standardization process is being carried out by the IEEE 
13 64 Working Group, so that this language may be considered 
10 as a standard de facto in the field of electronic design 
automation. 

[49] Behavior data 21 is a template file, preferably 
written in a proprietary language so as to simplify the 
designer's activity according to proprietary standards and 
15 habits. One skilled in the art easily understands that 
such a proprietary language, which will be described in 
detail later on, may be replaced by any other suitable 
proprietary or non proprietary language. 

[50] The same applies to configuration data 22, which is 
20 used to input configuration data for a test session. Such 
configuration data is preferably input to the generator 10 
through the command line, but any other suitable means may 
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be used. For instance, it is possible to write a number of 
text files, each storing a different configuration, and 
passing them to the generator either by hand or through a 
batch file. 

5 [51] The test bench generator 1 parses the behavior data 
21 and configures the memory model 20 according to the 
configuration data 22, generating a configured memory model 
20 1 . 

[52] It then parses each characteristic of the memory 
10 model 2 0 and seeks for matching information in the general 
memory models stored in the repository 10, so as to define 
whether a test is applicable or is to be applied to the 
memory model 20. If so, the test is added to the test 
bench 30, otherwise the test is skipped. 
15 [53] In the preferred embodiment, the input data passed 
to the generator 1 are translated into self -checking 
Verilog test benches, which include self -checking models 
incorporating complex constructs such as comparing data, 
waiting for internal events and timing constraint checking. 
20 [54] So doing, the generator guarantees that an 
exhaustive test bench is generated for the memory model to 
be verified, in that all possible known tests are 
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performed, with no need to rely on the designer to know 
which test to apply and thus waste time setting up each 
different test. 

[55] The generated test bench 3 0 is then inputted to the 
5 simulator 2, which reads the now fully configured memory 
model 20 1 and applies the test bench 30. The simulator 2, 
for instance, may be an incorporated Verilog simulator. 

[56] An adequate timing scale driving the simulation, as 
known in the art, may be entered, for instance through a 
10 "timings" file 23. 

[57] At the end of the simulation process, a set of 
reports 4 0 is produced, informing the designer about the 
outcome of the verification process. 

[58] In the preferred embodiment, the input given to the 
15 generator 1 for generating self-testing benches are of two 

types: Command line arguments 22 and a Template file 21. 

[59] The designer preferably specifies the memory 

configuration through command line arguments, which are 

detailed hereafter. 
20 [60] The behavior of the memory model under test is 

detailed using an input file called "Template", an 

explanation and a sample of which will follow. 
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[61] A proprietary language has been designed for 
specifying memory behavior. 

[62] As soon as the designer has specified the 
configuration and the memory behavior of a memory to be 
5 verified, the generator 1 starts generating an appropriate 
test bench to cover all of the aspects of the 
specification. 

[63] Based on the number of signals to be handled and on 
the values each signal can take, a fully exhaustive test 

10 bench is generated. 

[64] The signals used for memory modeling are grouped 
into seven categories: Reference signals, Control signals, 
Data bus signals, Mask signals, Address bus signals, Output 
control signals and Output port signals. 

15 [65] Depending on the memory type, which can be either 
synchronous or asynchronous, a reference signal may or may 
not exist. In general, it is assumed that for a given 
memory design only one reference signal per cycle exists. 
[66] Control signals control the functioning of the 

2 0 designed memory, and any number of control signals is 
allowed for a given memory. Examples are the "WEN" or 
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Write enable signal and the "CSN" or "Chip select pin" 
signal . 

[67] Data bus signals are in charge of carrying data, 
and they are described depending on the memory type, 
5 whether read-only or not, in that they are of significance 
only for cycles during which data has to be written to 
memory locations. Mask signals include any signal used for 
masking other signals, be they data, address or output 
signals. Address bus signals carry the memory location 

10 value according to which data has to be either accessed or 
written. Output control signals are generally asynchronous 
signals controlling the access to an output port, which 
changes its state in accordance with the value of the 
output control signal. Output port signals indicate the 

15 one signal associated to an output port. Memory test 
benches are based on cycles: particularly, the generator 1 
handles Read Cycle, Write Cycle, Normal Write Through 
Cycle, Data Write Cycle and Data Write Through Cycle tests. 
[68] A Read cycle means that data from a specified 

20 memory location is read and seen on an output port. A 
Write cycle means that data is written to a specified 
memory location. A Data write cycle means that a 
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continuous stream of data is written to a specified memory 
location. The last data in the stream is the one that is 
finally retained, or written, at the memory location. 
[6 9] A Normal Write Through Cycle means that data is 
5 written to a specified memory location and that at the same 
time it is seen at an output port. This situation occurs 
when the read address and the write address are the same 
for a given cycle for a memory port. 

[70] A Data write through cycle means that a continuous 
10 stream of data is written to the specified memory location 
and at the same time it is seen at the output port. This 
occurs when the read address and the write address of the 
memory are the same for a given cycle for a memory port. 
The last data in the stream is the one that is finally 
15 retained, or written, at the memory location. 

[71] As already mentioned, Functional, Timing, Edge 
type, Ftype, Ttype and Simultaneous access tests are 
available for each cycle. 

[72] Functional test cases are generated for testing the 
20 functionality of the memory that is, if the cycles show the 
expected behavior for which they were designed, either in 
response to legal and illegal signal values. 
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[73] Timing test cases are generated for verifying the 
memory behavior under various timing constraints such as, 
for instance, setup time, hold time, pulse width low, pulse 
width high and so on. Again, the behavior is tested 
5 against various legal and illegal signal values. 

[74] Edge type test cases are generated for testing 
simultaneously both the functionality and the timing 
constraints of a memory, and they are valid only for 
synchronous memories. In such test cases, a signal other 
10 than a reference signal changes its value as the edge of 
the reference signal changes. They are a special type of 
setup tests, where the setup time of any signal is taken to 
be zero. 

[75] Ftype test cases are generated for testing 
15 simultaneously both the functionality and the timing 
constraints of a memory, and they are valid only for 
synchronous memories. In such test cases, a signal other 
than a reference signal changes its value after a 
considerable lapse of time, then the edge of the reference 
20 signal changes. They are a special type of setup test, 
where the setup of time of any signal is taken to be 
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greater than the original setup time, according to 
designer 1 s definition. 

[76] Ttype test cases are applicable to synchronous 
memories only. In such test cases, a signal other than the 
5 reference signal changes its value after a considerable 
lapse of time, then the edge of the reference signal 
changes and some other signal is already showing a 
violation condition such as setup, hold, pulse width low 
and so on. 

10 [77] Simultaneous access test cases are generated for 
memories with more than one port, that is dual or multi- 
port, to verify simultaneous access behavior, and they are 
designed to test both the functionality and the timing 
constraints for a memory. 

15 [78] The output 30 of the generator is a Verilog test 
bench and a Header file. 

[79] The Verilog test bench comprises several files, 
including a file containing algorithms for calls to each 
type of the mentioned test cases and include files needed 
20 to run a simulation; a file containing the definition of 
each cycle type; a file containing a self -testing 
algorithm; a file containing functional test cases; a file 
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containing timing and ttype test cases; a file containing 
edge and ftype test cases; a file containing simultaneous 
access test cases. 

[80] The test bench is generated hierarchically, first 
5 with regard to test on a port basis, then with regard to 
tests on a port on a cycle basis and finally for each 
signal defined in a cycle. 

[81] The header file contains all the declarations 
related to input, output, register, type variables and so 
10 on, in a way which is similar to a typical C header file. 
The instantiating model is also given in the Header file, 
which is written in Verilog. 

[82] FIGURE 2 discloses the whole generation process 
according to the preferred embodiment of the present 

15 invention as performed by the generator 1. 

[83] At steps 101 and 102, the generator 1 reads memory 
configuration data 22 from the command line and memory 
behavior data 21 from a template, according to algorithms 
200 and 250 respectively. At step 103 a number of global 

20 variables is accordingly declared and initialized. 
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[84] At step 104 Verilog reference cycles corresponding 
to the memory cycles described in the input file are 
generated and written to file, according to algorithm 300. 
[85] At step 105 all the self-testing Verilog tasks are 
5 then generated and written to file, according to algorithm 
350. 

[86] A number of tests are then unconditionally 
generated and written to file at steps 106-109, including 
tests to write valid data at known memory addresses 

10 (according to algorithm 400) , tests to read data at known 
memory addresses (according to algorithm 450) , tests to 
make calls to self-testing tasks (according to algorithm 
500) and tests to generate stimuli for functionality checks 
for memory (according to algorithm 550) . 

15 [87] The generator then verifies, at step 110, whether 
"edge" and/or "ftype" Verilog tests are applicable to the 
memory model under test and, if so, such tests are 
generated at step 111 according to algorithm 600 and 
written to the file. 

20 [88] At step 112, stimuli for timing checks for memory 
are generated and written to the file, according to 
algorithm 650. 
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[89] Should the number of ports in the memory be greater 
than 1 (step 113), stimuli for simultaneous access checks 
for memory are generated and written to the file at step 
114, according to algorithm 700. 
5 [90] Finally, at step 115, a header file is generated, 
containing variable, register and signal declarations in 
Verilog or in the chosen HDL, according to algorithm 750. 

[91] Algorithm 250 is shown in FIGURE 3 in its general 
embodiment. The read memory configuration process 200 
10 starts by checking (step 201) the number of arguments 
passed to the generator, in whatever form they are actually 
defined. For instance, the check may be made on the 
content of a configuration file or in the number of 
arguments passed through the command line to the 
15 application program. 

[92] If the outcome of the check is negative, 
information is printed on screen explaining the correct use 
of the generator (step 2 02) . Otherwise the flow continues 
to step 203, where the first argument is read. 
20 [93] Broadly speaking, arguments may be of two different 
types, hereby identified as information parameters and 
language tokens. 

22 
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[94] An information parameter is an argument that asks 
the generator to provide feedback to the user, for instance 
to print help information or a list of currently set 
values . 

5 [95] A language token is an argument that is used to 
enter actual configuration data, like the model name of the 
memory model, the number of test words or test values. 
[96] In the former case (step 204) , the generator 
performs the required action (step 205) and then either 

10 stops execution or goes on to the next argument, depending 
on the actual parameter; in the latter case (206) , the 
generator stores data in a corresponding global variable 
(step 207) , and then checks (step 208) whether further 
arguments are available. If so, the algorithm loops back 

15 to step 2 03 to read the next argument, otherwise it 
performs a check (step 209) on the current value of global 
variables, and sets default values in the case that some of 
these variables have not been initialized. 
[97] A list of tokens made available in the preferred 

20 embodiment is provided below: 

-modelname: memory model name. Same as included in 
the Header File for memory model instantiation. 
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-bits: number of bits per word. 

-twords: number of words sampled per set to test 
the status of the memory model . 

-twin: test window to be used for timing tests. 
5 -step: step size for the reference signal 

transition. 

-ford n: order of the functional tests to be 
conducted. 

-edge n: order for the checks to be performed on 
10 reference signal transition. 

-ftype n: order for the ftype checks, 
-ttype n: order for the ttype checks, 
-simcombupto n: number of port combinations to be 
accessed simultaneously, in case of a mult i -port memory. 
15 -simcombreadcyc <YES/N0>: the type of memory cycle 

combinations to be generated for simultaneous access. 

NO: print all those simultaneous access combination 
for memory cycles that have one write cycle at least. 

YES: print all types of memory cycle combinations. 
20 -simviol <VN/W>: type of simultaneous access 

combinations to be generated for timing checks 
(hold/setup) . 
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VN: one port memory cycle has a signal timing 
violation and the other ports have normal memory cycle. 

W: all ports have memory cycles in which one signal 
has a timing violation and no port has a normal memory 
5 cycle. 

-template: specify the template file name and path, 
-tfile: specify the name of the output test bench 

file. 

-hfile: specify the header file name. 
10 -headertype: set the format of the header file to 

be generated, either BUS or BIT (splitted bus) . 

-rom: generate Verilog test benches for ROMs. 

-rep: specify the name of an output file containing 
simulation results as performed by the simulator 2. 
15 -cm: control monitor, turn off the monitoring of 

signals during self -testing that is, setting of signals and 
reading of signals before and after each test case is 
executed, to maximize speed and reduce the size of the 
output file. 

20 -h: print a detailed message on the available 

command line options. 

-u: print generator usage and execution command 
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information. 

-d: debug mode, output the internal data structure 
built after reading the template file. 

[98] A data flow diagram exploded from the data flow 
5 diagram of FIGURE 3 in conjunction with the list of tokens 
above is given as reference in FIGURE 4 . 

[99] Going back to FIGURE 2, block 250 refers to the 
reading of memory behavior from a template file 21, written 
in a proprietary language which will be now described in 

10 detail with referral to FIGURE 5. 

[100] The template file begins with a specific construct, 
for instance "TEMPLATE <library name> <model name>" and 
ends with "END TEMPLATE", and is divided into two main 
blocks 51 and 52 . 

15 [101] The first block 51 holds the description of the 
ports, such as the number of memory ports, the port names 
and the type of the ports (Read, Write, Read-Write) . 
[102] The second block 52 describes the cycles and 
behavior of the port. For each port, blocks 51 and 52 are 

20 repeated with the relevant information needed for testing 
and describing both the memory structure and its behavior. 
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[103] The port definition, which corresponds to block 52, 
is in turn divided into six sub-blocks 61-66, which contain 
a description of the signal, of the memory cycles supported 
by the model and of the behavior of each port (the modeling 
5 style) , and a specification on how the memory model is 
expected to behave when the signals take different values. 
[104] All the text between a "##" symbol and the end of 
a line is considered as a comment. List items are separated 
using a comma 11 , 11 , while statements are terminated by a 
10 semi-colon 11 ; " . 

[105] In more detail, block 51 defines the beginning of 
the memory model description file. 

[10 6] The "library name" parameter is an alpha-numeric 
value that specifies the technology for which the memory 
15 model has been designed. 

[107] The "model name" parameter is another alpha-numeric 
value which specifies the name of the memory model, the 
description of which is being defined in the file. 

[108] The »'MEM_TYPE <SYNC/ASYNC>" instruction is used to 
20 define the type of the memory, which can be either 
synchronous or asynchronous. "SYNC" indicates that the 
memory type is synchronous, and that a reference signal 
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therefore exists; "ASYNC" indicates that the memory under 
test is asynchronous, and that no reference signal exists. 
[109] The "NUM_OF_PORT <constant>" statement defines the 
number of ports supported by the memory model, wherein 
5 "constant" is an integer numeric value. 
[110] The following statement 
TYPE PORT 

PORT <port name> <port type> 
CONTENTION <time> 

10 END PORT 

defines the type of the ports that are supported by the 
memory model. The port description statements are enclosed 
within "TYPE PORT" and "END TYPE" keywords. The "PORT" 
statement is then repeated depending on the number of ports 

15 available in the memory model to be verified. 

[Ill] Particularly, the port name is an alpha-numeric 
value which specifies the name of the port as described in 
the memory model, and port type is used to set the type of 
the port. This is an alphabetic value selected from the 

20 following group: "R", to indicate a read only port, "W" for 
a write only port and "RW" for a read-write port. 
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[112] The "CONTENTION" statement is used to define the 
time difference between two sampling edges of the clock 
when two ports are accessed simultaneously, and it is set 
through the "time" parameter, which is a positive integer 
5 value. This statement is used for memories with more than 
one port and with non-zero contention time only. 
[113] Block 52 defines the cycles and behavior of the 
memory with regard to a certain port. The entire 
description is enclosed within a "BEGIN PORT" and "END 

10 PORT" block. The block is repeated depending upon the 
number of ports that exist for the memory model under test. 
[114] Block 61 is needed whenever a memory model has more 
than one read type port, to specify from which port the 
read operation shall be performed and to check the contents 

15 of the memory. 

[115] If the port is of the read-write type ("RW"), 
reading the memory contents onto the same port is allowed. 
On the other hand, memories with more than one read port 
need the above statements, as it is the case when the port 

20 is of the write type ("W"), in that it is necessary to 
access a read port to read memory contents after any 
testing operation is performed on the port. 
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[116] The "port name" parameter is an alpha-numeric value 
specifying the name of the port. An "ALL_PORTS " parameter 
is provided to specify that a read operation is to be 
performed from all the existing read-only ("R") and read- 
5 write ("RW") ports defined in the memory model. 
[117] Block 62, which is defined as 
DEFINE SIGNAL 
ADDR < words > <var> 
DATA <var> 

10 OUTP <var> 

END DEFINE 

stores information related to signals, including addresses, 
data and active outputs for a port. According to the type 
of a port, it will be appreciated that that "ADDR" and 

15 "DATA" are required for a Write-only port, "ADDR" and 
"OUTP" are required for a Read-only port and "ADDR", "DATA" 
and "OUTP" are required for a Read-Write port. 
[118] All the information is enclosed within "DEFINE" and 
"END DEFINE" statements. 

20 [119] The "words" parameter specifies the number of words 
for the memory port, and is used to extract information 
concerning the number of address lines. 
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[120] The "var" parameter defines the name of the address 
or data or output variable as defined in the memory model 
for the port . 

[121] Block 63, which is defined as "FTYPE <signal 
5 combination list>", details information related to "FTYPE" 
tests . 

[122] The <signal combination list> parameter defines the 
signal types for which the tests have to be performed, 
choosing from the list of keywords: "CTRL", "MASK", "DATA", 
10 "ADDR" and "OCTRL" . 

[123] Block 64, which is defined as 
BEGIN TTYPE 

FOR <signal type> <time list/SIMULT> TEST 
<signal combination list> 
15 ... 

END TTYPE 

details information related to "TTYPE" tests. 
[124] The block is enclosed within "BEGIN TTYPE" and "END 
TTYPE" statements. The "FOR" statement describes the 
20 details related to the type of test vector to be generated 
and can be repeated several times within the same block 
depending on the memory functionality to be verified. 
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[125] The statements specify information concerning 
signals that will show a violation condition and signals 
whose value will change after a violation has occurred. 
[126] The "signal type" parameter specifies the signal 
5 type, which again can be "CTRL", "MASK" , "DATA", "ADDR" or 
"OCTRL" . 

[127] The "signal name" parameter specifies the name of 
the signal as defined in the memory model, and can be 
entered in alpha-numeric form. 
10 [128] The "time list" parameter specifies the type of 
violation to be forced on the signal, selected from the 
group which comprises : "SETUP " , "HOLD" , "PWL" , "PWH" , 
"PER", "SIMULT" . 

[129] The "signal combination list" parameter defines the 
15 signal types for which the tests have to be performed, 
choosing from the same list of keywords: "CTRL", "MASK", 
"DATA", "ADDR" and "OCTRL". 

[130] Depending on the value of the "TTYPE" variable, the 
list may vary. 
20 [131] Block 65, which is defined as 

BEGIN < cycle name> 
Signal description blocks 
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END < cycle name>" 
indicates the cycles supported by the memory port. 
[13 2] The block is repeated depending on the number of 
5 cycles defined for the port. The basic description 
includes the definition of each signal type, including its 
active value, test values, setup and hold timings. 
[133] The Verilog test vectors that will be generated at 
the end of the process take their signal values from the 
10 information described in this section. The exhaust iveness 
of the test cases will also depend on the information 
detailed in the cycle definition block. 

[134] The entire information related to a particular 
cycle is enclosed within "BEGIN" and "END" statements 

15 followed by the cycle name, as defined by the designer. 

[135] As already mentioned, the commonly supported cycles 
for any memory are: Read cycle, Write Cycle, Normal Write 
Through Cycle, Data Write Cycle, Data Write Through Cycle. 
[136] A Signal Description Block is defined as shown 

20 below: 

BEGIN <signal type> <signal name> 
PWL <time> 
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list> 



list> 



list> 



PWH <time> 

PERIOD <time> 

PWLTRANS <reference signal transition 

PWHTRANS <reference signal transition 

PERTRANS <reference signal transition 

TRANS <signal transition list> 

10 ACTIVEDGE <edge type> 

SETUPEDGE <edge type> 

HOLDEDGE <edge type> 

SIZE <bit size of the signal> 

ACTIVE <value> 
15 TESTALSO <value list> 

ADDR_FULL_UNKNOWN 

ADDR_PARTIAL__UNKNOWN 

SET <time> BEFORE < reference signal name> 
SET <time> AFTER < reference signal name> 
20 SET <timel> BEFORE/AFTER THRU <time2> 

BEFORE/AFTER <reference signal name> 
END < signal type> 
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[137] The signal description is enclosed within "BEGIN" 
and "END" statements followed by a definition of the signal 
type. 

[138] It is assumed that all the memory signals are 
5 grouped into the already mentioned seven different signal 
types, which are understood by the generator according to 
the following wordings: "REF" for reference signals; "CTRL" 
for control signals; "MASK" for mask signals; "ADDR" for 
address bus; "DATA" for data bus; "OUTP" for output signal; 

10 "OCTRL" for output control signal. 

[139] The designer can select any type for various 
signals defined in the memory model and define its 
attributes in the signal description block. There is no 
limit defined for the number of signals that can be defined 

15 for the cycle, provided that each signal bears a unique 
name . 

[140] The order of the statements within the signal 
description block is not important: however the statements 
cannot be repeated within the same block, with the 
20 exception of "SET" statements (timing description) . 

[141] The "BEGIN <signal type> <signal name>" statement 
defines the beginning of the signal description block. The 
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"signal type" parameter specifies a signal type selected 
from one of the aforementioned seven categories, while the 
"signal name" parameter is an alpha-numeric value 
specifying the name of the signal as defined in the memory 
5 model for that cycle of the port for which the signal 
description block is being described. 

[142] The "PWL <time>" statement is specific to the 
Reference signal type, and it is used by the designer to 
define the Pulse Width Low time for the reference signal, 
10 for instance the Clock, through the "time" parameter, which 
is an integer value. 

[143] The "PWH <time>" statement is specific to the 
Reference signal type, and it is used by the designer to 
define the Pulse Width High time for the reference signal, 
15 for instance the Clock, through the "time" parameter, which 
is an integer value. 

[144] The "PERIOD <time>" statement is specific to the 
Reference signal type, and it is used by the designer to 
define the total cycle time for the reference signal, for 
20 instance the Clock, through the "time" parameter, which is 
an integer value. It is mandatory that the "PERIOD" 
statement be accompanied by a "PWL" statement. 
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[145] The "PWLTRANS <reference signal transition list>" 
statement is specific to the Reference signal type and is 
used to define transitions for the Pulse Width Low states 
of the reference signal. For example, a transition "0-1-0" 
5 implies that the reference signal is of the type shown in 
FIGURE 6a. The statement has no meaning if a "PWL" 
statement has not been specified in the signal description 
block. 

[146] The "reference signal transition list" parameter is 
10 the list of the reference signal transitions for which the 
test vectors have to be generated. A comma "," is used as 
a separator in the list. Each transition is five 
characters long, and a hyphen "-" is used as a separator 
for each value. Allowed values are: "0", "1", "X" and "Z". 
15 [147] The "PWHTRANS <reference signal transition list>" 
parameter is specific to the Reference signal type and is 
used to define transitions for the Pulse Width High states 
of the reference signal. For example, a transition 1-0-1 
implies that the reference signal is of the type shown in 
20 FIGURE 6b. The statement has no meaning if a "PWH" 
statement has not been specified in the signal description 
block. 
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[148] The "reference signal transition list" parameter is 
the list of the reference signal transitions for which the 
test vectors have to be generated. A comma "," is used as 
a separator in the list. Each transition is five 
5 characters long, and a hyphen "-" is used as a separator 
for each value. Allowed values are: "0", "1", "X" and "Z". 
[149] The "PERTRANS <reference signal transition list>" 
statement is specific to the Reference signal type and is 
used to define a transition for the reference signal. The 
10 statement has no meaning if both the "PWL" and "PERIOD" 
statements have not been specified in the signal 
description block. 

[150] The "reference signal transition list" parameter is 
the list of the reference signal transitions for which the 

15 test vectors have to be generated. It has been noticed 
that the best results from the tests are obtained when 
valid transitions for "PERIOD" checking are: "0-1-x", "0-1- 
z", "1-0-x", "1-0-z", "x-0-1", "z-0-1", "x-1-0", "z-1-0". 
[151] The "TRANS <signal transition list>" statement is 

20 applicable to all signal types except for reference 
signals, and is used to define the signal transition from 
one state to another. This is mainly used for Setup 
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Violation, Hold Violation, Edge type tests, Ftype type 
tests and Ttype type tests. 

[152] The "signal transition list" parameter is the list 
of signal transitions for which the test vectors have to be 
5 generated. Commas "," are used as a separator in the list. 
Each transition is three characters long, with a hyphen "-" 
as a separator between two values. Allowed values are: 
"0", "1", "X", "Z", for instance "0-1", "0-x". 
[153] The "ACTIVEDGE <edge type>" statement is applicable 
10 to all signal types except for reference signals, and is 
used to define the active edge of the signal with respect 
to the reference signal. Supported "edge type" values are 
"RISE" and "FALL". 

[154] The "SETUPEDGE <edge type>" statement is applicable 
15 to all signal types except for reference signals. This 
statement is usable only if the signal shows the setup 
condition at an edge other than the active edge defined in 
the "ACTIVEDGE" statement. These statements are specific 
to signals that show timing constraints (synchronous 
2 0 signals) . Supported "edge type" values are "RISE" and 
"FALL" . 

[155] The "HOLDEDGE <edge type>" statement is applicable 
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to all signal types except for reference signals. This 
statement is usable only if the signal shows the hold 
condition at an edge other than the active edge defined in 
the "ACTIVEDGE " statement. These statements are specific 
5 to signals that show timing constraints, for example, 
synchronous signals. Supported "edge type" values are 
"RISE" and "FALL". 

[156] The "SIZE <bit size of the signal>" statement is 
applicable to all signal types except for reference signals 

10 and is used to specify the size of the signals. 

[157] The "bit size of the signal" parameter can be 
specified through three different approaches: using the 
"DBITS" keyword if the size is equal to data bus size, 
using the "ABITS" keyword is the size is equal to address 

15 bus, using a numeric value otherwise . 

[158] The "ACTIVE <value>" statement is applicable to all 
signal types except for reference signals. Each signal has 
its active value at which it performs the legal operation, 
hence the statement to specify the same is required. The 

20 value parameter can be either "0" or "1". 

[159] The "TESTALSO <value list>" statement is applicable 
to all signal types except for reference signals. 
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[160] The test cases are mainly generated to test the 
memory functionality at its active legal value and to check 
the memory behavior at various illegal states of the 
signal . 

5 [161] The value list parameter is a list of values 
separated by a comma " , " . Allowed values are: " 0", "1", 
11 x" / " z 11 

[162] The " ADDR_FULL__UNKNO WN " statement is specific to 
address type ("ADDR") signals and instructs the generator 
10 to generate test cases so that memory behavior can be 
verified when a totally unknown address signal is passed. 
[163] The " ADDR_PART I AL_UNKNOWN " statement is specific to 
address type ("ADDR") signals and instructs the generator 
to generate test cases so that the memory behavior can be 
15 verified when a partially unknown ("OxOx") address signal 
is passed. 

[164] The "SET <time> BEFORE <reference signal name>" 
instructs the generator to generate test cases to verify 
the "SETUP" conditions for the memory. 
20 [165] The "time" parameter is the setup time for the 
signal, while the "reference signal name" parameter is the 
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name of the reference signal against which the setup 
condition has to be verified. 

[166] The "SET <time> AFTER <reference signal name>" 
statement instructs the generator to generate test cases to 
5 verify the "HOLD" conditions for the memory. 

[167] The time parameter is the hold time for the signal 
and is either a numeric value or a variable defined in the 
"Timings" file. 

[168] The "reference signal name" parameter is the name 
10 of the reference signal against which the hold condition 
has to be verified. 

[169] The "SET <timel> BEFORE /AFTER THRU <time2> 
BEFORE/AFTER <reference signal name>" statement specifies 
that applying different transitions from "timel" 
15 before/after to "time2" before/after the reference signal 
transition, in incremental time steps, should test the 
signal . 

[170] The "END <signal type>" statement defines the end 
of the signal description block, while the "signal type" 
20 parameter specifies the signal type from the already 
mentioned seven categories. 

[171] Block 66 is defined as 
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BEGIN BEHAVIOR 

Memory behavior blocks . . . 

END BEHAVIOR 

and specifies the memory behavior under normal or legal 
5 conditions. In addition, it also defines how the memory 
behaves when an illegal signal value is encountered at any 
signal . 

[172] One "BEHAVIOR" block must be defined for each 
"PORT" block. The block has two main sections: a first one 

10 which regards the normal behavior of all cycles defined for 
the port and a second one which regards the behavior of the 
memory and port output for various test values . 
[173] The first section takes the following form: 
DEFINE NORMAL < cycle name> 

15 START AT REF <reference signal name> <edge 

type> 

COND <data & address states> 
OUTP = MEM <operation> <output mask signal > 
MEM = DATA <operation> <data mask signal > 
20 ADDR = ADDR <operation> <address mask 



signal> 



TEST <test list> 
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END NORMAL 

[174] The normal behavioral description of the memory is 
enclosed within "DEFINE NORMAL" and "END NORMAL" 
statements. The block is repeated depending upon the 
5 number of cycle definitions defined for the port. 

[175] The "cycle name" parameter value has to be 
identical to that defined in the cycle description block 
for synchronization. 

[176] The "START AT REF <reference signal name> <edge 
10 type>" statement specifies the active edge for the 
reference signal at which the cycle begins. 
[177] The "reference signal name" parameter is the name 
of the reference signal defined for the cycle, while the 
"edge type" parameter is selected from the group which 
15 comprises: "RISE", "FALL", which are primarily used for 
synchronous memories and "CHANGE", which is primarily used 
for asynchronous memories . 

[178] The "COND <data & address states>" statement 
describes the memory behavior with respect to the state of 
2 0 the data and address bus. 



Dallas2 983884 v 1, 32079. 00087USPX 



44 



PATENT APPLICATION 
Docket #32079/87uspx 



[179] For instance, when defining a Normal Write Through 
cycle, the read address and the write address are same, and 
the corresponding statement is: "COND ADDR EQ" . 
[180] Similarly when defining the Data Write Through 
5 cycle, the read address and the write address are same 
while the data keeps changing its value. The statement 
will then be defined as "COND ADDR EQ && DATA CHANGE". 
[181] The "data state" parameter is set to "DATA CHANGE", 
and the "address state" parameter is "ADDR EQ", while the 

10 "&&" operator is used as a relational "AND" operator to 
define more than one condition. 
[182] The following statement 

OUTP = MEM <operation> <output mask signal > 
MEM = DATA <operation> <data mask signal > 

15 ADDR = ADDR <operation> <address mask 

signal > 

describes the transformations that may need to be done on 
the output, memory and address signals. 

[183] The "operation" parameter is one of the boolean 
20 operators: "AND" , "OR" and "XOR" or "MSK" , for Mask. 

[184] For example, when defining a Read cycle, the data 
at the memory address is shown on the output port; hence 
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the statements used to define will be: "OUTP = MEM " and 
"ADDR = ADDR" . The equation "MEM = DATA" is not needed as 
there is no data being written onto the memory. 
[185] Similarly, to define the Write cycle, all the three 
5 equations will be used: "OUTP = MEM", "MEM = DATA" and 
"ADDR = ADDR" . 

[186] The "TEST <test list>" statement is used to add a 
self -checking of the memory when a test is not comprised in 
the standard checking mechanism pool embedded in the 
10 generator. This statement defines the default tests to be 
conducted for the specific cycle when the action for any 
particular signal value combination is not specified in the 
BEHAVIOR block. 

[187] The "test list" parameter can be either "MEM" or 
15 "OUTP". "MEM" tests are used when the contents of the 
memory need to be tested and "OUTP" for testing the output 
port. For example, in the case of a Read cycle, the output 
port needs to be tested; hence the statement will be: TEST 
OUTP. 

20 [188] In the case, of a Write cycle, the memory contents 
need to be tested; hence the statement will be: TEST MEM. 
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[189] Finally, in the case, of a Normal Write Through 
cycle the memory contents as well as the output port need 
to be tested; hence the statement will be: "TEST MEM, 
OUTP" . 

5 [190] The second section is defined as: 

DEFINE ALIAS <cycle name 1> 
WHEN <cycle name 2> <signal name> <signal 

value> 

END DEFINE 

10 [191] At times, it is observed that the behavior of one 
cycle is identical to other if the signal value changes for 
certain pins. For instance, in the case of a "WEN" (write 
enable) instruction, a "LOW" ("0") indicates Write Cycle 
whereas a "HIGH" ("1") indicates Read Cycle. "ALIAS" 

15 statements help in simplifying the description of such 
memory behavior. 

[192] The "cycle name 1" parameter is the name of the 
cycle for which the alias or substituting condition is 
being defined; the "cycle name 2" parameter is the name of 
20 the cycle which will be substituted; the "signal name" 
parameter is the name of the signal as defined in the 
signal description block for the cycle and the "signal 
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value" parameter is the signal value, which is generally- 
set to "0" or "1" . 

[193] As an example, the following piece of code: 
DEFINE ALIAS WRITE_CYCLE 
5 WHEN READ_CYCLE WEN 0; 

END DEFINE 

implies that a Read Cycle aliases to a Write Cycle if "WEN" 
changes to "0". Hence, the generator will automatically 
know to test for a Write Cycle behavior. 
10 [194] The following statement 

DEFINE <cell state> 

WHEN 

• • > 

END DEFINE 

15 describes memory behavior behaving in an abnormal way, as 
it occurs under certain violation conditions. 
[195] The "cell state" parameter indicates the state of 
a cell. Such states are broadly classified as Memory 
states and Port states. 

2 0 [196] Memory states are listed below, together with 
keywords activating such states: 

CORRUPT_ENTIRE_MEM: corrupt entire memory. The 
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entire memory data at all locations is set to "X". 

CORRUPT_LATCHED_LOC : corrupt latched location. The 
memory data at a particular location is set to "X" . 

MEMORY_NOCHANGE : memory no change. The memory data 
5 at all locations remains unchanged with respect to its 
previous state . 

CORRUPT JDATAJB I T_MEM: corrupt data bit memory. The 
entire data is not wholly corrupted, but some bits only are 
set to "X" . 

10 CORRUPT_MASK_BIT_MEM: corrupt mask bit memory. The 

mask signal is not corrupted only some bits are to X. 
[197] Port states are listed below: 

PORT_UNKN : port unknown. The output port is all 
set to "X. " 

15 PORT__HIZ: port high impedance. The output port is 

all set to "Z". 

PORT_NOCHANGE : port no change. The output port 
remains unchanged with respect to its previous state. 
[198] The following statement 
2 0 DEFINE OVERFLOW 

WHEN 
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END DEFINE 

describes an overflow condition, which occurs when a memory 
is accessed beyond the word limit for which it had been 
designed. 

5 [199] With regard to Signal State Description, the 
following statements are used to describe the signal 
behavior and violation conditions: 

<cycle name> <signal type> <signal name> IS 
<violation 
10 condition 1> 

<cycle name> <signal type> <signal name> <violation 
condition 2> 

< cycle name> < signal type> < signal name> TRANS 

<signal transition list> 
15 [2 00] The "cycle name" parameter is the name of the cycle 

for which the self testing is being defined. If the 

parameter is set to "ALL_CYCLES" , then the same test has to 

be repeated for all cycles described for that port. 

[201] The "signal type" parameter indicates one of the 
20 seven categories supported by the generator: "REF", "CTRL", 

"ADDR" , "DATA", "MASK", "OCTRL", "OUTP", which have been 

already explained. 
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[2 02] The "signal name" parameter is the name of the 
signal defined for the type being described in the 
statements, which should be the same as defined in the 
signal description block of the port, for a given cycle. 
5 [203] The "violation condition 1" parameter is a signal 
state which causes an abnormal memory behavior, and takes 
one of the following values: "X" if the signal is fully 
unknown; "P" , if the signal is partially unknown, "Z", if 
the signal is at high impedance, "1" or "0" if the signal 
10 shows a corresponding value, "O" to define an address 
overflow condition. 

[204] The "violation condition 2" parameter is a signal 
state which causes an abnormal memory behavior, and is 
selected from: "PWL", if the signal shows pulse width low 

15 violation; "PWH", if the signal shows pulse width high 
violation; "PER", if the signal shows period violation. 
[205] The above statements are in context to the 
reference signal only, while the following are applicable 
to any signal type, except for reference signals: "SETUP", 

20 if the signal shows setup violation; "HOLD", if the signal 
shows hold violation; "SIMULTANEOUS", if the signal is 
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under simultaneous access (requires that a simultaneous 
access behavioral block be defined) . 

[206] The "signal transition list" parameter indicates 
the signal transitions causing an abnormal memory behavior, 
5 which is, in general, in context to the reference signals. 
[207] The following statement: 

DEFINE SIMULT 

WHEN 

10 END DEFINE 

defines the conditions for testing the memory and output 
port under simultaneous access, in case of memories having 
more than one port . 

[2 08] The signal state description and violation 
15 conditions thereof are defined through the following 
statements : 

SIM CYCLE < cycle name 1> CYCLE < cycle name 2> 
< signal type> < signal name> SIMULTANEOUS, 

where the two "cycle name" parameters indicate the cycles 
20 that are being simultaneously accessed from the two 
different ports, and "signal type" is the type of the 
signal, out of the aforementioned seven categories, and 
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"signal name" is the name of the common signal between the 
two cycle of two different ports. 

[209] A sample of a template is provided for illustrative 
purposes below: 
5 ## defining the write cycle block. 

## We mention the signals and its description. 
BEGIN WRITE_CYCLE 

## if the memory is synchronous the reference 

signal 

10 ## is defined. 

DEFINE REF CK 

## defining the active edge for the reference 

signal . 

15 ACTIVEDGE RISE; 

## define the reference signal transitions for 

which 

## functionality is to be tested. 
TRANS 0-1-X, 1-0-Z; 
20 END REF 

## define the control signal and its description. 
DEFINE CTRL WEN 
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ACTIVEDGE RISE; SIZE 1; ACTIVE 0; 

## mention the values for which the signal 
## functionality has to be tested. 
5 TESTASLO X, Z; TRANS 0-X, 0-Z; . . . 

END CTRL 

## define the data signal and its description. 
DEFINE DATA D 

10 SIZE DBITS; ACTIVEDGE RISE; 

## mention the values for which the signal 
## functionality has to be tested. 

TESTALSO Z, X; TRANS 0-X, Z-0; . . . 
END DATA 

15 ## define the address signal and its description. 

DEFINE ADDR A 

ACTIVEDGE RISE; SIZE ABITS; 

## mention the values for which the signal 
20 ## functionality has to be tested. 

TESTALSO 0X01; TRANS 0001 -ZZZZ, 0001- 

0X0X; . . . 
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END ADDR 
## end of write cycle block. 
END WRITE_CYCLE 

## defining the read cycle block. We mention the 
5 ## signals and its description. 

BEGIN READ_CYCLE 

## if the memory is synchronous the reference 

signal 

## is defined. 
10 DEFINE REF CK 

... 

## defining the active edge for the reference 

signal . 

ACTIVEDGE RISE; 

15 ## define the reference signal transitions for 

which 

## functionality is to be tested. 

TRANS 0-1-X, 1-0-Z; 
END REF 

20 ## define the control signal and its description. 

DEFINE CTRL WEN 



55 

Dallas2 983884 v 1, 32079. 0008 7USPX 



PATENT APPLICATION 
Docket #32079/87uspx 



ACTIVEDGE RISE; SIZE 1; ACTIVE 1 ; 
## mention the values for which the signal 
## functionality has to be tested. 

TESTASLO X, Z; TRANS 1-X, 1-Z; . . . 
5 END CTRL 

## define the output control signal and its 
## description. 
DEFINE OCTRL OEN 

10 SIZE 1; ACTIVE 0; 

## mention the values for which the signal 
## functionality has to be tested. 

TESTALSO 1, Z, X; TRANS 0-X, 0-1;... 
END OCTRL 

15 ## define the address signal and its description. 

DEFINE ADDR A 

ACTIVEDGE RISE; SIZE ABITS; 

## mention the values for which the signal 
20 ## functionality has to be tested. 

TESTALSO 0X01; TRANS 0001 -XXXX, 0001- 

0X0X; . . . 
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END ADDR 

## define the output signal and its description. 
DEFINE OUTP Q 

SIZE DBITS; ACTIVEDGE RISE; ... 
END OUTP 
## end of read cycle block. 
END READ_CYCLE 
BEGIN BEHAVIOR 

## memory gets corrupted if any or all conditions 
## defined in the block is true. 
DEFINE CORRUPT_ENT I RE_MEM 
WHEN 

## for any cycle supported by the memory if the 
## control signal named CSN goes X or Z. 

ALL_CYCLES CTRL CSN X/Z; 
## for any cycle supported by the memory if the 
## control signal named CSN shows a setup or hold 
## violation. 

ALL_CYCLES CTRL CSN SETUP/HOLD; 
## for write cycle if the address signal named A 
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## becomes unknown or partially unknown. 

WRITE_CYCLE ADDR A X/P; 
END DEFINE 

## The output port shows Z if any or all conditions 
5 ## defined in the block are true. 

DEFINE PORT_HIZ 
WHEN 

## for any cycle supported by the memory if the 

output 

10 ## control signal named OEN goes 1. 

ALL_CYCLES OCTRL OEN IS 1 ; 
END DEFINE 

• • • 

END BEHAVIOR 

15 [210] Going now back to algorithm 250, the basic function 
of the algorithm is to read the template file and store the 
relevant data in an array, so as to simply access for later 
processing. At the same time, the format and error 
checking for the template file is performed. 

20 [211] The storing of information is based on a 
hierarchical model based on a tree structure describing the 
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organization of the internal data structure and spread on 
different levels. 

[212] All the information related to the memory model is 
stored at level 1. Such information refers to: "model 
5 name", "library name", "memory type" and "number of ports". 

[213] Data concerning each port is stored at level 2, 
wherein each port block includes one or more cycle blocks 
and one behavior block, as shown in FIGURE 4 . 

[214] Level 3 stores data related to each of the cycles, 
10 which data includes information on a plurality of signals. 

[215] The behavioral block of data stores three types of 
information: the normal behavior description for each 
cycle; information for memory violations; information for 
port violations. 
15 [216] Level 4 stores data for each signal, including 
Size, Activedge, Trans, TestAlso, Timing and so on. 

[217] FIGURE 7 is a data flow diagram illustrating 
algorithm 300, according to which reference memory cycles 
are generated. The basic idea behind this function is to 
20 generate the Verilog code for cycles whose behavior has 
been described in the input template file 21, and takes 
into account that the file, as already explained, is 
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structured in a hierarchical manner and contains 
information for cycles in each memory port. Verilog code 
for each cycle of the port is laid down in an output file. 

[218] Referring to FIGURE 7, the first port name in the 
5 memory model is retrieved at step 301. 

[219] At step 302, the first cycle name is fetched and a 
check is performed at step 3 03 to verify whether a 
reference signal is defined for that cycle. 

[220] If so, Verilog code for cycles generated using data 
10 from input file for synchronous memories is added to output 
file 3 06 at step 3 04, otherwise Verilog code for cycles 
generated using data from input file for asynchronous 
memories is adapted at step 305. 

[221] At step 307, the generator checks whether a further 
15 cycle definition exists for the selected port and, if so, 
loops back to step 3 02. 

[222] When the inner loop terminates, the generator 
checks (step 308) whether the port definition exists for 
the memory under test and, if so, loops back to step 302. 
20 The outer loop is then quit and the generator returns to 
its main function. 
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[223] The output file 306 contains the reference cycle 
definitions for both synchronous and asynchronous memories. 
In the case of asynchronous memories, cycles related to 
timing checks are not needed, hence not coded, in that no 
5 reference signal obviously exists. 

[224] On the contrary, in the case of synchronous 
memories, the reference signal is a key player, so that the 
Verilog code for pulse width low (PWL) , pulse width high 

(PLH) and period checks are all defined. All the 
10 information needed to code the reference cycle is again 
obtained from the input template file 21. 

[225] Referring to the generator's design strategy, it is 
possible for the user to define the behavior of the cycle, 
which, as shown, is described in the behavioral block of 
15 the input template file 21. Samples in pseudo-code follow, 
one concerning synchronous memory and one concerning 
asynchronous memory, to better clarify how behavior data is 
entered in the template file 21: 

// The cycle definition is within the task block of 
20 // the Verilog. 

task <name of the cycle>; 
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// All the input parameters and register 
declaration 

// is set at the beginning of the task. A given 
// reference signal can be described using five 8- 

5 bit 

// characters, for example, 0-1-0, 0-1 -x. To take 

the 

// reference signal value as input, an input 

// parameter which is 4 0 -bit long must be defined. 

10 input [8*5-1:0] value; 

//an input parameter storing timing information 
// related to pwl, pwh or period has to be 32 -bit 
// long. 

input [31:0] l_time; 

15 // A reference signal makes three transitions. For 

// example, 0-1 -x. To store each value we need to 
// declare registers, first=0, second=l and 

third=x. 

// reg first, second, third; other temporary 
20 // variables/registers can be declared on need. 

// Beginning of the task declaration. 
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begin 

// The generator supports generation of reference 
// signal with valid values (0, 1) or others. 
//To generate a normal reference transitions, the 
5 // input parameter "value" equals NORM, else it is 

// specified as "V-V-V" , where "V" can be 0, 1, x, 

z 

if ( value equals "NORM" ) 
then 

10 // Registers "first", "second" and "third" will 

hold 

// reference signal transition states, 
first = active value of reference signal (one can 
obtain from the input file.) 
15 second = not of first 

third = first 
else 

//In this case the second case holds true (V-V-V) , 
// where "V" can be [OlXxZz] . Here, the first is 
20 // stored at bits 39:32, the second at bits 23:16 

and 
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the 



high 



when 



20 



// third at bits 7:0, where the other bits store 



// character " 



5 endif 

// separate reference cycles are generated for each 
// tyP e of timing checks - pwl, pwh, period and 
/ / normal . 

if ( reference cycle type equals "PWL" ) 
10 // code to check for pulse width low violation when 

// the reference signal makes a transition from 



// state to low. 



15 else if ( reference cycle type equals !, PWH M ) 

// code to check for pulse width high violation 



// the reference signal makes a transition from low 
// state to high. 

else if (reference cycle type equals "PER" ) 
// code to check for period violation 
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else 

// the normal cycle code with out any violation, 

the 

5 // reference signal changes its value at each step. 

endif 
end 

// end of the task declaration. 
10 endtask 

[226] With regard to asynchronous memory, a signal value 
can trigger a cycle. This signal is defined in the input 
file. To explain the Verilog code generated by the 
generator for different cycles, the following the pseudo 
15 code is provided: 

// The cycle definition is within the task block 

of 

// the Verilog. 
task <name of the cycle>; 
20 // other temporary variables/registers can be 

declared 

// on need. 
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// Beginning of the task declaration, 
begin 

#$STEP; 

5 #$STEP <signal assigned the new value 

(transition) >; 

#$STEP; 
end 

// end of the task declaration. 

10 endtask 

[227] FIGURE 8 shows the algorithm 350 for generating 
self -testing routines. The algorithm is in charge of 
generating the Verilog code that contains routines to test 
the behavior of the memory, such as corrupt entire memory, 

15 corrupt latched location, port unknown, and the like. The 
Verilog code is written to an output file. Each port has 
an explicitly declared routine for it, as the behavioral 
checks are cycle independent . 

[228] At step 3 51, the port name supporting a read cycle 
20 is read. At Step 352 1 Verilog code for performing specific 
memory testing is written to file, according to a 
corresponding algorithm 3 53'. 
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[22 9] The data flow diagram is exploded in FIGURE 9, 
where it is shown that the memory test bench includes tests 
concerning corruption of entire memory, corruption of 
latched locations, memory when no change occurs, unknown 
5 ports, ports at high impedance, ports when no change 
occurs, corruption of data bits in memory and corruption 
of a mask bit in memory. 

[23 0] At step 368 the algorithm checks whether a next 
Read Port definition exists for the type of memory under 

10 test. If so, the flow loops back to step 351, otherwise 
goes on to steps 369 and 370, where the port name is first 
read, followed by the cycle name. The Verilog code for 
testing normal cycle behavior is then generated and written 
to the output file (step 371), according to algorithm 372. 

15 [231] The basic functionality for testing the memory 
behavior is coded in the behavior block of the input 
Template file 21, to compare the output at the port with 
the expected output . 

[232] If a cycle definition exists (step 373) for the 
20 selected port, the flow loops back to step 369, otherwise 
it is checked whether a port definition exists (step 374) 
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for the memory under test, in which case the flow goes back 
to step 369. 

[233] In the exploded data flow diagram of FIGURE 9, 
which relates to a preferred embodiment, each of steps 352 
5 to 359 refers to a specific test, which is generated to a 
corresponding algorithm 360 to 367. 

[234] Algorithm 360 tests for corrupt entire memory, and 
generates Verilog code to force a read cycle on the port 
under test. If the data at all locations equals unknown 
10 ("X" value), then it is assumed that the entire memory has 
been corrupted. Otherwise, a statement to flash a message 
in a report file is written. 

[235] Algorithm 361 tests for corrupt latched location 
(M-4.2) and generates Verilog code to force a read cycle 

15 on the address location that can be corrupted due to a 
violation. If the data at that location (address) equals 
unknown, then it is assumed that the latched location has 
been corrupted, else a statement to flash a message in the 
report file is written. 

20 [236] Algorithm 362 tests for memory no change and 
generates Verilog code to force a read cycle on all address 
locations. If the data at all locations (addresses) equals 
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its previous value, then it is assumed that the data at 
memory locations has not been changed, otherwise a 
statement to flash a message in the report file is written. 
[237] Algorithm 363 tests for port unknown. Whenever the 
5 task is invoked, it checks if the output port is unknown, 
else a statement to flash an error message in the report 
file is generated. 

[238] Algorithm 364 is suitable for testing a port at 
high impedance. Whenever the task is invoked, it checks 

10 if the output port is set to "Z" , else a statement to flash 
an error message in the report file is generated. 
[239] Algorithm 365 tests for port no change. Whenever 
the task is invoked, it checks if the output port is 
showing the previous data, else a statement to flash an 

15 error message in the report file is generated. 

[240] Algorithm 366 tests for corrupt data bit memory. 
In case of certain signal violations, some bits of the data 
are corrupted. To check for such cases, it is first needed 
to find what value is expected at the output port and a 

20 read cycle is forced at the specified memory address and 
finally the output at the port is compared with the 
calculated value. If the two values do not match, a 
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statement to flash an error message is generated in the 
report file. 

[241] Algorithm 366 tests for corrupt mask bit for 
memory. In case of certain signal violations, some bits 
5 of the mask are corrupted. To check for such cases, it is 
first needed to know what value is expected at the output 
port, then a read cycle is forced at the specified memory 
address and finally the output at the port is compared with 
the calculated value. If the two values do not match, a 
10 statement to flash an error message in the report file is 
written. 

[242] Going back to the data flow diagram of FIGURE 2, 
algorithm 4 00 generates tasks to write valid data onto 
memory. The aim of this function is to generate Verilog 
15 code for tasks that can force a write cycle onto memory 
addresses, the generator being knowledgeable about what 
data has been stored. These tasks are mainly used for 
writing self -checking routines, as the generator has the 
knowledge about the expected output, each time a test case 
20 is simulated. 

[243] Different tasks exist for each separate port. In 
addition, the number of memory locations that will be 
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written depends upon the TWORDS variable, which is set by 
the designer. 

[244] The following is an example in pseudo code to 
better clarify the algorithm: 
5 task SetMemContents; 

// Setting (Writing) the memory contents, declare 
// input parameters 

begin 

10 for ( i=0; i<number of TWORDS; i++ ) 

begin 

// at location i, data written to memory is also 

i/ 

// that is Address=l, Data=l. 
15 write cycle invoked at address i (data=i) ; 

end 
end 

endtask 

[245] Supposing that TWORDS is set to "5" , the memory 
20 contents in the different steps will be: Address=0, Data=0; 
Address=l, Data=l; Address=2, Data=2 ; Address=3, Data=3 ; 
Address=4 , Data=4 . 
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[246] Algorithm 450 generates tasks to read data from 
memory. The aim of this function is to generate Verilog 
code for a task that can force a read cycle onto a memory 
address, and is explained by the following pseudo-code. 
5 Tasks exist for each separate port. In addition, the 
number of memory locations that will be read depends on the 
TWORDS variable, which is set by the designer. The code 
is : 



task GetMemContents; 



10 



// Get (Reading) the memory contents. Declare input 



// parameters 



begin 



for ( i=0; i<number of TWORDS; i++ ) 



15 



begin 



// under ideal conditions, at location i, output 



// equals i, that is Address=l, Data=l, Output =i . 



read cycle invoked at address i; 



end 



20 



end 



endtask 
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[247] Under ideal conditions, when a legal operation has 
been performed on the memory, and supposing that TWORDS is 
set to "5", the expected result when the GetMemContents 
task is invoked will be: Address=0, Data=0, Output=0; 
5 Address=l, Data=l, Output=l; Address=2, Data=2, 0utput=2; 
Address=3, Data=3, 0utput=3; Address=4, Data=4, 0utput=4 . 
[248] Algorithm 500 makes calls to self -testing tasks. 
The behavioral section of the input or template file 
defines the signal conditions for which the memory behaves 
10 in a abnormal manner and hence self -checking routines need 
to be invoked. Such a function encodes the data from input 
file into Verilog language so that the self -checking tasks 
can be invoked. 

[249] For instance, on a single port memory supporting 
15 write cycle and read cycle only, the behavioral block of 
the input template file could be as follows. 
[250] The function accesses information from the data 
structure created while parsing the input file, and for 
each cycle in each port, the codes are converted into 
20 Verilog code and written to an output file. The code is: 
// self testing task for write cycle 
task <name of the task 
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n callSelfTestingForWriteCycle">; 

// input parameter declaration 

f lagTest=l; 

5 // all the conditions as mentioned in the input 

file. 

// if any one of the condition is true then self 
// testing task has to be called, 
if ( CSN equals X "or" 
10 CSN equals Z "or" 

CSN shows setup violation "or" 
CSN shows hold violation "or" 
A equals X "or" A equals P ) 
then 

15 // call to task for checking if the entire memory 

has 

// been corrupted. 
checkForCor rupt Ent i reMemeory ; 

// if the memory behavior has been tested once then 
20 // the normal operation of the cycle is not 

required 

// to be checked, hence the flag is set to false. 
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5 the 



flagTest = 0; 
end if 

if ( flagTest ) 

// if none of the above checks were done to test 
// memory behavior, call to task for checking if 



write 

// cycle was normal. 
checkForNormalWriteCycle ; 
10 endif 

endtask 

// self testing task for read cycle 
task <name of the task 

"callSelfTestingForReadCycle" >; 
15 // input parameter declaration 

f lagTest=l ; 

// all the conditions as mentioned in the input 

file. 

2 0 //if any one of the condition is true then self 

// testing task has to be called, 
if ( CSN equals X "or" 
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CSN equals Z "or" 

CSN shows setup violation "or" 

CSN shows hold violation ) 

then 

// call to task for checking if the entire memory 



has 



// been corrupted. 
checkForCorruptEntireMemeory; 

//if the memory behavior has been tested once then 
10 // the normal operation of the cycle is not 

required 

// to be checked, hence the flag is set to false, 
f lagTest=0; 
end if 

15 if ( OEN equals 1 ) 

then 

// call to task for checking if the output port 

reads 

// Z. 

2 0 checkForPor t Z ; 

// if the memory behavior has been tested once then 
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// the normal operation of the cycle is not 

required 

// to be checked, hence the flag is set to false. 

flagTest = 0; 

endif 

if ( flagTest ) 

// if none of the above checks were done to test 



the 



10 read 



// memory behavior, call to task for checking if 



// cycle was normal. 
checkForNormalReadCycle ; 
endif 
endtask 

15 [251] Algorithm 550, which is shown in FIGURE 10, 
instantiates calls for functional test cases. 
[252] The "TESTALSO" statement in the input or template 
file defines the condition for which each signal has to be 
tested. Such tests fall under the functional test 

20 category. In addition, it is possible to define the ORDER 
of the functional tests ("1", "2", "3"). 
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[253] At steps 551 and 552 first the port name, then the 
cycle name is read, and at step 553 the Verilog code for 
functionality testing of memory is generated in accordance 
with algorithm 554. 
5 [2 54] At step 555 it is checked whether a cycle 
definition exists for the selected port, in which case the 
flow loops back to step 552. Otherwise, at step 556 it is 
checked whether a port definition exists for the memory 
under test, in which case the flow loops back to step 551. 
10 [255] Once this first loop is terminated, a second loop 
is started at step 557 by reading again the port name and, 
at step 558, the cycle name. 

[256] If the functional ORDER is set to a value 
comprised between "1" and "3", then Verilog calls to 
15 functional test cases with a corresponding signal value or 
values changing (1, 2 or 3) are generated at step 561, in 
accordance with algorithm 562, and the flow jumps to step 
563. 

[257] If the functional ORDER value is invalid, an error 
20 occurs at step 560 and the flow comes to an end. 

[2 58] At step 563 it is checked whether a further cycle 
definition exists for the selected port, in which case a 
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jump is made back to step 558, otherwise a jump is made 
from step 564 to step 557 in the case that a further port 
definition exists for the memory under test. 
[259] Algorithm 562 to write calls for the functional 
5 test cases is now explained through illustrative examples, 
supposing that a single port memory, which supports read 
and write cycles, is used. 

[2 60] The function accesses the above information from 
the data structure created while parsing the input template 
10 file. The information is then coded to get the functional 
test cases and written to an output file. 

[2 61] The following code refers to a Functional test with 
0RDER=1 : 

// functional testing routines for write cycle. 

15 For 

// order=l, only one signal value keeps changing 

while 

// other signals equal to their active values, 
task <name of the task "CallsToWriteCycle" >; 
20 begin 

// call to write cycle when all the signals take 

legal 
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// values, reference signal CK=NORM, control signal 
// WEN=0, address A=0 and data D=0 . 
// functionalTestWriteCycleCall ( CK, WEN, A, D ) ; 
functionalTestWriteCycleCall ( "NORM" , 1'bO, 4'bO, 



5 6 ' bO ) ; 



// now we take the other values of the signal and 
// invoke calls. call for reference signal CK. 
functionalTestWriteCycleCall ( "0-1-x", 1'bO, 4*b0, 

6 ' bO ) ; 

10 functionalTestWriteCycleCall ( "1-0-z", 1'bO, 4'bO, 

6 ' bO ) ; 

// call for control signal WEN. 

functionalTestWriteCycleCall ( "NORM", l'bx, 4'bO, 

6 ' bO ) ; 

15 functionalTestWriteCycleCall ( "NORM", l'bz, 4'bO, 

6 1 bO ) ; 

// call for data bus D. 

functionalTestWriteCycleCall ( "NORM", 1'bO, 4'bO, 

6 ■ bz ) ; 

20 functionalTestWriteCycleCall ( "NORM", 1'bO, 4'bO, 



6'bx ) 



// call for address bus A. 
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functionalTestWriteCycleCall ( "NORM" , 1 'bO, 
4'bOxOl, 6'bO ) ; 
end 

endtask 

5 // functional testing routines for read cycle. 

task <name of the task "CallsToReadCycle" >; 
begin 

// call to write cycle when all the signals take 

legal 

10 // values. reference signal CK=NORM, control 



signal 



A=0 



// WEN=0, output control signal OEN=0 and address 
// functionalTestWriteCycleCall ( CK, WEN, OEN, A 



15 ) ; 



functionalTestReadCycleCall ( "NORM", l'bl, 1'bO, 

4'b0 ) ; 

// now we take the other values of the signal and 
// invoke calls. call for reference signal CK. 
20 functionalTestReadCycleCall ( "0-1-x", l'bl, 1'bO, 

4 1 bO ) ; 
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functionalTestReadCycleCall ( "1-0-z", l'bl, 1'bO, 

4 'bO ) ; 

// call for control signal WEN. 

functionalTestReadCycleCall ( "NORM" , l'bx, 1'bO, 

5 4 'bO ) ; 

functionalTestReadCycleCall ( "NORM" , l'bz, 1'bO, 

4 • bO ) ; 

// call for output control signal OEN. 
functionalTestReadCycleCall ( "NORM", l'bl, l'bl, 

10 4 'bO ) ; 

functionalTestReadCycleCall ( "NORM", l'bl, l'bx, 

4 ' bO ) ; 

functionalTestReadCycleCall ( "NORM", l'bl, l'bz, 

4 ' bO ) ; 

15 // call for address bus A. 

functionalTestReadCycleCall ( "NORM", l'bl, 1'bO, 
4 'bOxOl) ; 

end 

endtask 

20 [262] The same applies to other cycles supported by the 
memory . 
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[263] The following code refers to a Functional test with 
ORDER- 2 : 

// functional testing routines for write cycle. 

For 

5 // order=2, signal value keeps changing for 2 

signals 

// while other signals equal to their active 

values . 

task <name of the task "CallsToWriteCycle" > ; 
10 begin 

// call to write cycle when all the signals take 

legal 

// values, reference signal CK=N0RM, control signal 
// WEN=0, address A=0 and data D=0. 
15 // functionalTestWriteCycleCall ( CK, WEN, A, D ) ; 

functionalTestWriteCycleCall ( "NORM", 1'bO, 4'bO, 

6'bO ) ; 

// now we take the other values of the signal and 
// invoke calls, call for CK & WEN. 
20 functionalTestWriteCycleCall ( "0-1-x", l'bx, 4 f b0, 

6 1 bO ) ; 
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functionalTestWriteCycleCall ( "0-1-x", l'bz, 4'bO, 

6 ' bO ) ; 

functionalTestWriteCycleCall ( "1-0-z" , l'bx, 4'bO, 

6 ' bO ) ; 

5 functionalTestWriteCycleCall ( "1-0-z", l'bz, 4'bO, 

6 1 bO ) ; 

// call for CK & D. 

functionalTestWriteCycleCall ( "0-1-x", 1'bO, 4'bO, 

6 'bz ) ; 

10 functionalTestWriteCycleCall ( "0-1-x", 1'bO, 4'bO, 

6 • bx ) ; 

functionalTestWriteCycleCall ( "1-0-z", 1'bO, 4'bO, 

6 -bz ) ; 

functionalTestWriteCycleCall ( "1-0-z", 1'bO, 4'bO, 

15 6 'bx ) ; 

// call for CK & A. 

functionalTestWriteCycleCall ( "0-1-x", 1'bO, 
4 'bOxOl, 6'bO ) ; 

functionalTestWriteCycleCall ( "1-0-z", 1'bO, 
20 4 'bOxOl, 6'bO ) ; 

// call for WEN & D 
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functionalTestWriteCycleCall ( "NORM" , l'bx, 4'bO, 

6 • bz ) ; 

functionalTestWriteCycleCall ( "NORM", l'bx, 4'bO, 

6 ■ bx ) ; 

5 functionalTestWriteCycleCall ( "NORM", I'bz, 4'bO, 

6 * bz ) ; 

functionalTestWriteCycleCall ( "NORM", l*bz, 4'bO, 

6 • bx ) ; 

// call for WEN & A 
10 functionalTestWriteCycleCall ( 

4 'bOxOl, 6 'bO ) ; 

functionalTestWriteCycleCall ( 
4 'bOxOl, 6 'bO ) ; 

// call for D & A 
15 functionalTestWriteCycleCall ( 

4'bOxOl, 6'bz ) ; 

functionalTestWriteCycleCall ( 
4 'bOxOl, 6 'bx ) ; 

end 

20 endtask 

[264] The same applies to other cycles supported by the 
memory . 
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[265] The following code refers to a Functional test with 
0RDER=3 : 

// functional testing routines for write cycle. For 
// order=3 / signal value keeps changing for 3 

5 signals 

// while other signals equal to their active 

values . 

task <name of the task "CallsToWriteCycle">; 
begin 

10 // call to write cycle when all the signals take 

legal 

// values, reference signal CK=NORM, control signal 
// WEN=0, address A=0 and data D=0. 
// functionalTestWriteCycleCall ( CK, WEN, A, D ) ; 
15 functionalTestWriteCycleCall ( "NORM" , I'bO, 4'bO, 



6'b0 ) ; 



20 6'bz ) ; 



6 ■ bx ) ; 



// take the other values of the signal and invoke 
// calls, call for CK & WEN & D. 

functionalTestWriteCycleCall ( "0-1-x", l'bx, 4'b0, 
functionalTestWriteCycleCall ( "0-1-x", l'bx, 4'b0, 
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functionalTestWriteCycleCall ( "0-1-x", l'bz, 4'bO, 

6 ■ bz ) ; 

functionalTestWriteCycleCall ( "0-1-x", l'bz, 4'bO, 

6 ■ bx ) ; 

5 functionalTestWriteCycleCall ( "1-0-z", l'bx, 4'bO, 

6 'bz ) ; 

functionalTestWriteCycleCall ( "1-0-z", l'bx, 4'bO, 

6'bx ) ,- 

functionalTestWriteCycleCall ( "1-0-z", l'bz, 4'bO, 

10 6'bz ) ; 

functionalTestWriteCycleCall ( "1-0-z", l'bz, 4'bO, 

6'bx ) ,- 

// call for CK & WEN & A. 

functionalTestWriteCycleCall ( "0-1-x", l'bx, 
15 4 'bOxOl, 6'bO ) ; 

functionalTestWriteCycleCall ( "0-1-x", l'bz, 
4'bOxOl, 6'b0 ) ; 

functionalTestWriteCycleCall ( "1-0-z", l'bx, 
4'bOxOl, 6'bO ) ; 
20 functionalTestWriteCycleCall ( "1-0-z", l'bz, 

4'b0x01, 6'bO ); 

// call for WEN & D & A. 
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functionalTestWriteCycleCall ( "NORM " , 1 »bx, 
4'bOxOl, 6'bz ) ; 

functionalTestWriteCycleCall ( "NORM" , 1 1 bx # 
4 'bOxOl, 6 ! bx ) ; 
5 functionalTestWriteCycleCall ( "NORM", l'bz, 

4 'bOxOl, 6 'bz ) ; 

functionalTestWriteCycleCall ( "NORM" , l'bz, 
4'bOxOl, 6'bx ) ; 

end 

10 endtask 

[266] The same applies to other cycles supported by the 
memory . 

[267] The above pseudo code illustrates how different 
types of functional test cases can be called. The basic 
15 operation is to force the cycle to occur and then perform 
a self -check on the memory, so as to report errors, if any, 
in a report file, 

[268] The following pseudo code is useful to understand 
the task calls, and refers to the previous example for a 
20 write cycle: 

// entire functional test case is written. 

task <name of task "functionalTestWriteCycleCall 1 ^; 
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// declare all the input parameters to store the 

signal 

// values as passed from the task 
"CallsToWriteCycle" . 

begin 

SetMemContents ; 

// Reset the memory contents to known values 

// Initialize all the signals for write cycle to 

10 the 

// values passed as parameters from 
"CallsToWriteCycle" 
// task. 

SetSignalValues ; 
15 WriteCycle; 

// invoke the write cycle 
callSelf TestingForWriteCycle; 
// invoke the self testing tasks 
GetMemContents 

20 // Read the contents of the memory, after each test 

// completion, 
end 
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endtask 

[269] The same applies to other cycles supported by the 
memory . 

[270] Algorithm 600, shown in Figure 11, instantiates 
5 calls for edge / ftype type test cases. 

[2 71] If the designer has included arguments to generate 
test cases for Edge and Ftype by selecting an order ("1" , 
"2", "3") then a corresponding function is called, in a way 
which is similar to the functional test cases algorithm. 

10 Both the Edge and Ftype test cases exist for only 
synchronous memories. The number of signals whose value 
changes is decided by the order stored in "EDGE" and 
"FTYPE" variables. The signal values are taken from the 
"TRANS" statement defined in the signal description block 

15 of the input template file. 

[272] With referral to FIGURE 11, at step 601 a check is 
made to verify whether an "EDGE" order exists. In that 
case, functions to generate edge type cases are executed, 
before moving on to step 602. 

20 [273] At step 603 the port name is read, then the cycle 
name at step 604. If, at step 605, the EDGE value is 
comprised between "1" and "3", then the Verilog code to 
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generate calls and test cases for EDGE with one, two or 
three signals changing is accordingly generated at step 607 
according to algorithm 608, otherwise an error occurs (step 
606) . 

5 [274] At step 609 it is checked whether a cycle 
definition exists for the selected port, in which case the 
flow loops back to step 604. Otherwise, at step 610 it is 
checked whether a port definition exists for the memory 
under test, in which case the flow loops back to step 603. 
10 [275] When no more port definitions exist for the memory 
under test, or if no EDGE order was defined, the flow 
branches to step 602, where the same operations are 
performed with regard to FTYPE orders. 

[276] Particularly, at step 611 the port name is read, 
15 then the cycle named at step 612. If, at step 613, the 
FTYPE value is comprised between 11 1" and "3", then the 
Verilog code to generate calls and test cases for FTYPE 
with one, two or three signals changing is accordingly 
generated at step 615 according to algorithm 616, otherwise 
20 an error occurs (step 615) . 

[277] At step 617 it is checked whether a cycle 
definition exists for the selected port, in which case the 
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flow loops back to step 612. Otherwise, at step 618 it is 
checked whether a port definition exists for the memory 
under test, in which case the flow loops back to step 611. 
[278] Algorithms 608 and 616 to generate calls and test 
5 cases for EDGE and FTYPE tests are now clarified through 
an illustrative example, in which a single port memory 
supports read and write cycles. 

[279] The function accesses such information from the 
data structure created while parsing the input Template 
10 file 21. The information is then coded to get the edge and 
ftype test cases and written to an output file. 
[280] The following three blocks of pseudo-code better 
clarify this activity: 

In the case of "EDGE order=l && FTYPE order=l" 
15 // edge type testing routines for write cycle for 

// address bus A, other signals equal to their 

active 

// values. 

task <name of the task 

20 " edgeCal 1 sToWr i t eCycleForA " > / 
begin 

// Call to edge type test for write cycle, where 
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// address signal changes its value and other 

signals 

// take legal values. Reference signal CK=NORM, 
// control signal WEN=0 and data D=0. 
5 // edgeTestWriteCycleCallForA ( WEN, AFirst, 

Asecond, 

// D ) ; 

edgeTestWriteCycleCallForA ( 1 ' bO , 4 1 bOOOl , 
4 'bzzzz, 6 *b0 ) ; 
10 edgeTestWriteCycleCallForA ( 1'bO, 4'bOOOl, 

4 f b0x0x, 6' bO ) ; 

end 

endtask 

// ftype type testing routines for write cycle for 
15 // address bus A, other signals equal to their 

active 

// values. 

task <name of the task 

11 f typeCallsToWriteCycleForA">; 
20 begin 

// Call to ftype type test for write cycle, where 
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// address signal changes its value and other 

signals 

// take legal values. Reference signal CK=NORM / 
// control signal WEN=0 and data D=0. 
5 // ftypeTestWriteCycleCallForA ( WEN, AFirst, 

Asecond, 

// D ) ; 

ftypeTestWriteCycleCallForA ( 1 'bO, 4 »b0001, 
4 1 bzzzz, 6 1 bO ) ; 
10 ftypeTestWriteCycleCallForA ( 1'bO, 4'bOOOl, 

4 , b0x0x / 6'bO ) ; 
end 

endtask 

[281] The same applies to other signals defined for each 
15 cycle of each port. 

[282] The following pseudo code refers to "EDGE order=2 

&& FTYPE order=2 " : 

// edge type testing routines for write cycle. For 
// order=2, signal value keeps changing for 2 

20 signals 

// while other signals equal to their active 

values . 
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task <name of the task 
" edgeCa lis ToWr i t eCy c 1 e For A_WEN 11 > ; 
begin 

// Call to edge type test for write cycle, where 
5 // address signal and control signal change their 

// values & other signals take legal values. 
// Reference signal CK=NORM , and data D=0. 
// edgeTestWriteCycleCallForA_WEN ( WENFirst, 
// WENSecond, AFirst, ASecond, D ) ; 
10 edgeTestWriteCycleCallForA_WEN (1 'bO, 1 'bx, 

4'b0001, 4'bzzzz, 6'bO) ; 

edgeTestWriteCycleCallForA_WEN 
( 1 1 bO , 1 1 bx, 4 1 bO 0 0 1 , 4 1 bOxOx, 6 1 bO ) ; 

edgeTestWriteCycleCallForA_WEN 
15 (1 'bO, 1 f bz, 4 'b0001 # 4 'bzzzz, 6 f b0) ; 

edgeTestWriteCycleCallForA_WEN ( 1 1 bO , 1 1 bz , 
4'bOOOl, 4'bOxOx, 6 ! b0); 
end 

endtask 

20 // ftype type testing routines for write cycle. For 

// order=2, signal value keeps changing for 2 

signals 
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// while other signals equal to their active 

values . 

task <name of the task 
"ftypeCall sToWr i t eCyc 1 e For A_WEN " > ; 
5 begin 

// Call to ftype type test for write cycle, where 
// address signal and control signal change their 
// values & other signals take legal values. 
// Reference signal CK=NORM, and data D=0. 
10 // ftypeTestWriteCycleCallForA_WEN ( WENFirst, 

// WENSecond, AFirst, ASecond, D ) ; 
f typeTestWriteCycleCallForAJtfEN ( 1 'bO, 1 'bx, 
4'bOOOl, 4'bzzzz, 6'b0 ); 

f typeTestWriteCycleCallForA_WEN ( 1 ' bO , 1 ■ bx, 
15 4'bOOOl, 4 , b0x0x, 6 ! b0 ); 

f typeTestWriteCycleCallForAJtfEN ( 1 1 bO , 1 1 bz , 
4'bOOOl, 4«bzzzz, 6 l b0 ); 

f typeTestWriteCycleCallForA_WEN ( 1 ' bO , 1 1 bz , 
4'bOOOl, 4'bOxOx, 6 f b0 ); 
20 end 

endtask 
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[283] The same applies to other signals defined for each 
cycle of each port . 

[284] The following pseudo code refers to "EDGE order=3 
ScSc FTYPE order=3" : 
5 // edge type testing routines for write cycle. For 

// order=3, signal value keeps changing for 3 

signals 

// while other signals equal to their active 

values . 

10 task <name of the task 

" edgeCal 1 sToWr i t eCyc 1 eForAJWENJD " > ; 
begin 

// Call to edge type test for write cycle, where 

// address signal, control signal and data signal 
15 // change their values and other signals take legal 

// values. Reference signal CK=N0RM. 

// edgeTestWriteCycleCallForA_WEN_D ( WENFirst, 

// WENSecond, AFirst, ASecond, Dfirst, DSecond ) ; 

edgeTestWriteCycleCallForA_WEN_D (1 f b0, 1 «bx, 

20 4'bOOOl, 4 , bzzzz / 6'bO, 6'bx); 

edgeTestWriteCycleCallForA_WEN_D (1 'bO, 1 'bx, 
4'b0001,4'b0x0x,6'b0, 6'bx) ; 
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edgeTestWriteCycleCallForA_WEN_D (1'bO, l'bz, 
4 'bOOOl, 4 'bzzzz, 6'bO, 6'bx); 

edgeTestWriteCycleCallForA_WEN_D (1 'bO, 1 'bz, 

4 'b0001,4 'bOxOx, 6'bO, 6'bx); 
5 edgeTestWriteCycleCallForA_WEN_D (1'bO, l'bx, 

4'bOOOl, 4'bzzzz, 6'bz, 6'bO); 

edgeTestWriteCycleCallForA_WEN_D (1 'bO, 1 'bx, 

4*b0001,4'b0x0x, 6'bz, 6'bO); 

edgeTestWriteCycleCallForA_WEN_D 
10 (I'b0,l'bz f 4'b0001, 4'bzzzz, 6'bz, 6'bO ); 

edgeTestWriteCycleCallForA_WEN_D (1'bO, l'bz, 
4 *b0001,4 'bOxOx, 6 'bz, 6'bO); 

end 

endtask 

15 // ftype type testing routines for write cycle. For 

// order=3, signal value keeps changing for 3 

signals 

// while other signals equal to their active 

values . 

20 task <name of the task 

" f typeCallsToWriteCycleForA_WEN_D" > ; 
begin 
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// Call to ftype type test for write cycle, where 

// address signal, control signal and data signal 

// change their values and other signals take legal 

// values. Reference signal CK=NORM. 
5 // ftypeTestWriteCycleCallForA_WEN_D ( WENFirst, 

// WENSecond, AFirst, ASecond, Dfirst, DSecond ) ; 

f typeTestWriteCycleCallForA_WEN_D (1 'bO, 1 'bx, 

4'b0001,4 'bzzzz, 6'bO, 6'bx); 

f t ypeTe s t Wr i t eCyc 1 eCal 1 For A_WEN_D 
10 (1 *b0, 1 'bx,4 'b0001,4 'bOxOx, 6'bO, 6'bx); 

f typeTestWriteCycleCal lForA_WEN_D 
(1 'bO, 1 'bz,4 'bOOOl, 4'bzzzz, 6'bO, 6'bx); 

ftypeTestWriteCycleCallForA_WEN_D (1'bO, l'bz, 
4'b0001,4 'bOxOx, 6'b0,6' bx ) ; 
15 ftypeTestWriteCycleCallForA_WEN_D (l'b0,l'bx, 

4 'b0001,4 'bzzzz, 6'bz, 6'bO); 

ftypeTestWriteCycleCallForA_WEN_D (1'bO, l'bx, 
4 'b0001,4 'bOxOx, 6 'bz, 6 'bO ) ; 

ftypeTestWriteCycleCallForA_WEN_D (1'bO, l'bz, 
20 4 »b0001,4 'bzzzz, 6'bz, 6'bO); 

ftypeTestWriteCycleCallForA_WEN_D (1 'bO, 1 'bz, 

4 'b0001,4 'bOxOx, 6'bz,6'b0 ) ; 
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end 

endtask 

[285] The same applies to other signals defined for each 
cycle of each port . 
5 [286] The above pseudo code shows how different types of 
edge and ftype type test cases can be called. The basic 
operation is to force the cycle to occur and then perform 
the self-check on the memory, so as to finally report 
errors, if any, in a report file. 
10 [287] The following pseudo code helps understanding the 
task calls, with reference to the above example, for write 
cycle and order=l: 

// entire edge type test case is written, 
task <name of task "edgeTestWriteCycleCallForA" >; 
15 // Store signal values passed as input parameters 

from 

// the task "edgeCallsToWriteCycleForA" . 
input WEN_e ; 
input [4-1:0] A_f, A_s; 
20 input [6-1:0] D_e; 

// declare temporary variables needed to generate 
// clock. 
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reg first; 
begin 

// task call to SetMemContents . This is done to 



reset 



5 // the memory contents to known values, to help in 

// self -checking. 
SetMemContents ; 

// Initialize all the signals for write cycle to 

the 

10 // values passed as parameter from 

/ / " edgeCal 1 sToWr i t eCyc 1 eForA " task. 
first=active value of the reference signal. 
$STEP CK=first; 

WEN, D set equal to their active values. 
15 A=A_f; 

#$STEP CK=~first; A=A_s ; 
#$STEP CK=first; 

// invoke the self testing tasks in case of a bug 

in 

20 // memory model error can be checked in a report 



file 



callSelf Test ingForWriteCycle ; 
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of 



10 >; 



from 



// task call to GetMemContents . Read the contents 

// the memory, after each testcompletion. 

GetMemContents . 

end 

// task declaration ends here, 
endtask 

// entire ftype type test case is written. 

task <name of task "f typeTestWriteCycleCallForA" 

// Store signal values passed as input parameters 



// the task " f typeCallsToWriteCycleForA" . 
input WEN_e; 
15 input [4-1:0] A_f, A_S; 

input [6-1:0] D_e; 

// declare temporary variables needed to generate 
// clock, 
reg first; 
20 begin 

// task call to SetMemContents . This is done to 

reset 
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5 the 



file 



20 of 



// the memory contents to known values, to help in 
// self -checking. 
SetMemContents ; 

// Initialize all the signals for write cycle to 



// values passed as parameter from 
// " f typeCallsToWriteCycleForA" task . 
first=active value of the reference signal. 
#$STEP CK=first; 
10 WEN, D set equal to their active values. 

A=A_f ; 

#$STEP CK=~first; 
#$STEP A=A_S; 
#$STEP CK=first; 
15 // invoke the self testing tasks in case of bug in 

// memory model error can be checked in a report 



callSelfTestingForWriteCycle; 

// task call to GetMemCon tents . Read the contents 

// the memory, after each test completion. 
GetMemContents . 
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end 

// task declaration ends here, 
endtask 

[288] The same applies to other signals for each cycle 
5 of each port supported by the memory. 

[289] Algorithm 650, shown in FIGURE 12, instantiates 
calls for timing test cases and is used to test the timing 
conditions such as pulse width low and high time for 
reference signals, and setup and hold time for other signal 

10 types for the memory under test. The "SET" statements in 
the input template file are used to define the timing 
values and the " TRANS 11 statements are used to define the 
signal transition values. For reference signals, the 
timing values and clock transitions are specified using the 

15 "PER", "PWL", "PWH", "PWLTRANS", "PWHTRANS", and "PERTRANS" 
statements . 

[290] At steps 651-652, Verilog tasks for timing test 
cases and Verilog tasks for calls to timing test cases are 
respectively generated. 
20 [291] At step 653 to 655 a check is made to verify 
whether the "TTYPE" order is comprised between "1" and "3", 
in which case Verilog tasks for TTYPE test cases of that 

104 

Dallas2 983884 v 1 , 32079. 00087USPX 



PATENT APPLICATION 
Docket #32079/87uspx 



order and corresponding calls are generated (step 654-656) . 
Otherwise, an error is reported. 

[292] Algorithm 700, shown in FIGURE 13, instantiates 
calls for simultaneous access test cases and is used to 
5 test the functioning of memories that have more than one 
port, so that multiple ports are operating simultaneously. 
[2 93] The "CONTENTION" statements in the input template 
file are used to define the access time between ports. 
Tests and cycles are generated for various combinations 

10 of simultaneous access, according to input parameters. 

[294] More in detail, at steps 701-702 Verilog tasks are 
generated with regard to simultaneous functional access 
test cases and corresponding calls, while at steps 703-704, 
the same kind of data is generated with regard to timing. 

15 [295] Algorithm 750, shown in FIGURE 14, generates a 
header file which provides all variable declarations and 
file handling through one common point. 

[296] At step 751 a port name is read, and a cycle name 
is read at step 752, followed by a signal name and 
20 structure taken from input data structure (step 753) . 

[297] Starting from this data, Verilog code for signal 
declaration is generated at step 754. 
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[298] At step 755 it is checked whether a further signal 
definition exists for the selected cycle, in which case the 
flow loops back to step 754 . 

[299] At step 756 it is checked whether a further cycle 
5 definition exists for the selected port, in which case the 
flow loops back to step 752 . 

[300] At step 757 it is checked whether a further port 
definition exists for the memory in issue, in which case 
the flow loops back to step 751. 
10 [301] Finally, at step 758, file operations are performed 
to write data to output files and then closing open files. 
[302] The following block shows the basic structure of 
a header file generated according to algorithm 750. 

// time scale declaration for the simulations. 
15 time . . . 

// input / output variable identification for the 
// memory 
output . . . 
input . . . 
20 // module declaration, 

module . . . 

// memory model instantiation. 
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<memory model name> <instance name> <signal 
declarations>; 

// variables declarations, 
reg . . . 

5 wire . . . 

integer . . . 

// file operations. Declarations so as the 
simulation 

// results can be written onto output files 
10 $f opens (. . .) 

// end of module declaration, 
end module 

[303] It has been shown that the present invention 
achieves the proposed aim and objects, providing designers 
15 of integrated circuits with a system and method that allow 
to generate comprehensive test benches in an easy and 
automatic manner. 

[304] A preferred embodiment has been detailed with 
regard to memory designing. Clearly, several modifications 
20 will be apparent to and can be readily made by the skilled 
in the art without departing from the scope of the present 
invention. Therefore, the scope of the claims shall not 
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be limited by the illustrations or the preferred 
embodiments given in the description in the form of 
examples, but rather the claims shall encompass all of the 
features of patentable novelty that reside in the present 
5 invention, including all the features that would be treated 
as equivalents by the skilled in the art. 
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